Google Cloud：Site Reliability Engineering（SRE）の基礎についてまとめた

SREとは

Site Reliability Engineering（以下SRE）とはGoogle社が提唱するいわばサービスを提供する上でのルールを定義した説明書のようなものです。

開発〜運用までの中で、どのように進めて行けば最もユーザーや開発者にとって有益となるかをまとめた原則とも言い換えられるかもしれません。
またSREと言われるように、Reliability＝信頼性こそがサービスを提供する上で最も重要な視点だと考えられています。

また、SREはお客さまへ提供するサービスの品質（全てひっくるめて）の向上を目的とするものであり、かつ提供する側（企業など）への配慮もしているという点を押さえて頂ければと思います。

Google公式ドキュメントから引用

SRE は、信頼性の高い本番環境システムを実行するための職務、マインドセット、エンジニアリング手法のセットです。

DevOps

DevOpsはSREとは異なる概念ではありますが、SREを適用することで効率的なDevOpsの実践につながり、理想的なサービスの運用が可能となるため、解説していきます。

サービスをリリースし提供していく中では、Developer担当である開発者とOperation担当である運用者の連携がとても重要になります。

開発では設計→開発→テスト→リリースまでを担当し、運用ではリリース以後の運用、保守、障害対応を担当します。

ただし、この一連の流れは単純なものではなく、いくつかの弊害を考慮し進めなければ効率の良い開発や運用、そして良いサービスの提供ができません。

そこでSREというルールに沿って開発〜運用を進めていくと、より良いサービスの提供が実現可能となるのです。

SREに登場する関連人物は、開発者、運用者、経営陣、お客さま...etc、など多岐に渡ります。
このDevOpsとSREは密接に関係しており、両方をうまく組み合わせることによりサービスの品質に良い影響を与えることができます。

Google公式ドキュメントから引用

DevOpsは、ソフトウェアデリバリーの速度とサービスの信頼性の向上、ソフトウェアの関係者間で共有するオーナー権限の構築を目的とする、組織的で文化的な仕組みです。

Ops

Devである開発についてはわかりやすいかと思いますが、Opsの運用もSREを語る上ではとても重要な要素になってきます。

例えば、サービスをリリースした直後から正常性を監視し続け、もし障害が起きた場合には何らかの対処を行わなければなりません。

この時の道筋として使用できるのがSREに則った対応であり、それは運用前の開発段階から策定しておく必要があります。

今あげた例は（障害対応）一部に過ぎませんが、このようにあらゆる環境下でSREの概念が役に立ってきます。

そしてOps担当者は正常なサービス運用が主担当であり、それを犯すリスクがある行動は取りたくありません。（リスクある作業＝新しい機能の追加やバージョンアップ..etc）

しかし、企業側（経営陣や開発者）は企業の成長や理念、目的の達成のためにサービスの改善やアップデートをユーザーに届けたいという要望があるかと思います。

こういった異なる立ち位置から生じるニーズの違いを顧慮しながら進めていく為にも、SREの原則に則ったサービス開発/運用が大事になってきます。

自動化

異なる立ち位置から生じるニーズの違いを埋めるために必須なのが、自動化というアプローチです。

なるべく人手の作業を介さずに開発や運用に必要な各フェーズを行うことで、最大限リスクを回避し、開発者と運用者のニーズへのバランスが取れるようになります。

結局は企業は1つであり、ニーズの違いはロール（担当）によって変化するだけです。良いサービスを提供したいという思いは全ての担当者で変わりはありません。

そしてこの自動化というアプローチに最も適している環境がクラウドになると思います。

物理的な管理作業はGoogleやAWSなどのクラウドベンダーに任せているため、仮想OSより上のレイヤーから担当する我々ユーザーは既に存在するさまざまなサービスを駆使して、SREに則り、自動化を採用したアプローチを選択することができます。

さまざまなサービスの例として、Google Cloud Deployment ManagerやTerraformといったインフラ構築を自動化するサービスや、ログ分析やリソース監視などを行えるOperation Suiteに含まれるマネージドサービスを活用することが出来るため、これらを利用することでSREの原則に沿った開発・運用を効率よく実現することが可能です。

Deployment Manager の基礎知識
Google Cloud のオペレーション スイートの概要

一旦概要はこの辺にして、重要となる語句の解説に移りたいと思います。

用語解説

ここからはSREに関連した用語の説明になりますが、全ての用語を挙げているわけではありません。
私が重要だと思う語句を最低限挙げておりますので、少しでも勉強の参考になれば幸いです。

SLI (Service Level Indicator)

SLIは、実際にユーザーが体験するサービスの重要な機能における成功イベントでの指標となります。

例えば自社サイトを立ち上げたとして、HPのトップ画面を開くスピード（レスポンスタイム）がユーザー目線に立ち不満がないレベルで指標を作成します。

（例） 「HPを開くのが5秒 → 不満」 「HPを開くのが2秒 → 満足」

この場合、成功のイベントを2秒と定義するのでSLIはトップページを開く動作で2秒となります。
ただし、その該当となるイベントは（今回はHPのトップページの表示時間）いくつもあるため、イベントの選定が必要になります。

その他の例

可用性のSLI ： HTTPリクエストの成功率が99.9%以上であることを指標に設定する。
エラーレートのSLI ： エラーが発生する割合の程度。システム全体で発生するエラーの割合を指標に設定する。（全体の0.1%を許容するなど）

SLO (Service Level Objective)

SLIで設定した指標内でイベントが完了した回数が、全てのイベント数内でどれだけ達成できれば良いかを数値化したものになります。
よって、SLIで設定した指標を達成する目標の割合を示すのがSLOです。

先の例のように、SLIが2秒以内にトップページが表示されることを指標としている場合、SLOはそのSLIが全体のどれくらいの割合で達成されるべきかを示します。

（例） SLIを2秒と定義 ： 合計100回のイベントのうち、2秒以内でトップページを表示された回数が99回であれば、SLOを99%以上と定義することができます

よって、SLOを定義する際の大事な考慮事項として、リリース前のテストで100回中、99回成功（＝99%）したならば、実際にSLOを定義するのは98%などにする必要があるということです。
（ただし、サービスの要件に応じてSLOの目標値を柔軟に設定することが重要です）

実際にユーザーへ提供する指標にもなるので、本番でも許容できる範囲で設定することが重要になります。

SLA (Service Level Agreement)

ユーザーへの補償を提供するために必要な指標がこのSLAになります。
例えば、SLAで99%を定めたとして、その指標が99%を下回った場合には、返金やそのサービスで使用できるクレジットを還元することになります。

Google CloudのサービスであるCloud Spannerでは、SLAが99.999%と驚異的な数字を出しています。
これは年間の許容ダウンタイムで言うと、およそ5.26分となります。週単位で見ると6秒です。

Cloud Spanner Service Level Agreement (SLA)

このSLAを補償できるGoogle Cloudの技術力は 「さすがです！」 としか言いようがありませんが、 逆にSLAの内容が低すぎる場合には、ユーザーが選ぶサービスから外れてしまう可能性も考えられるので、かなり慎重に決めることが重要です。

（例） SLIが99.9%、SLOが99.5%ので計測した場合、実際のSLAは99%あたりで設定する （あくまでも例です）

これをあえて95%にすることで企業的な損失（補償による分配）は逃れられるかもしれませんが、ユーザーがSLAの％を見て選択を拒否した場合には、機会損失につながってしまうという事になります。

エラーバジェット (Error Budgets)

冒頭でも触れた立場から生じるニーズの違いの間をうまく取り持つのがエラーバジェットになります。（新規開発のニーズと安定稼働のニーズ、など）

エラー予算とも言い換えることができ、SLOと実際のシステムパフォーマンスの差を示す指標です。

SLOを達成している限り、エラーバジェットは消費されませんが、SLOを下回るパフォーマンスが発生した場合、エラーバジェットが消費されることになります。
SLOを99％にした場合、月/7.2時間のシステムの停止などが許容されます。

もし6月のエラーバジェットの消費が1時間だった場合には余っている6.2時間を何か他の作業に回すことができます。
（例えば新規開発や他チームへの援助など）

逆にエラーバジェットをギリギリ使用している場合などには、エラーの修正や安定性の向上に努める必要が出てきます。
これが冒頭で触れたDevとOpsチームのニーズの違いの間を取り持つ所以です。

ポストモーテム (Post Mortem)

インシデントが起きた際に行う事後分析になります。根本原因や再発の防止を定義し、文書の作成なども行います。

ポストモーテムの大きな意義としては、インシデントを契機にシステムやプロセスを改善し、組織全体の成長につなげることです。

今回は具体的な手順は割愛しますが、適切に実施することでサービスのシステムの安定性が向上し、インシデント発生後の信頼性の確保と共に、その後の顧客への満足度などにも影響を与えます。

すごく簡単にまとめると、「インシデントを起こしても、その再発を防止し、さらに良いサービスにするためにもう一度色々と見直し、改善しましょう」といった具合です。

まとめ

今回はSREエンジニアリングの基礎として基本的な考え方と、用語の解説をしました。
個々の用語をつなぎ合わせた紹介は最低限に留めております。
開発や運用に関する知識や経験が浅い方が、SREやDevOpsについて学習する際の入門としてこの情報が参考になれば幸いです。

最後に

前職が元パーソナルトレーナーであったため、ダイエット情報や筋トレ情報を積極的に配信したいと思っています！！IT＝脳＝運動＝体調管理⇒全ては繋がっています。

ナッツも太りますよって話

今回は何かと健康食としてTVで紹介されるナッツについて、ダイエット視点で解説します。

ナッツはダイエットにいいのか？？
ズバリYESです。ただ、いくつか条件があります。

基本的に、ナッツ類は高カロリーです。なぜなら脂質を多く含む食品であり、逆に糖質は少ない種類が多いです。（アーモンド、くるみ...etc）
1gのカロリーを見ると、糖質＝4kcal、脂質9kcalになるので、脂質を多く含むナッツは太りやすいと言い換えられることもできます。

ただし、その脂質には、オメガ3脂肪酸という、いわゆる健康に良いと呼ばれる成分を含んでいるため、積極的に摂取したい栄養素で、動物性脂肪と比べると、体内にも蓄積されにくいと言われています。

【亜麻仁オイルにも含まれる】

メリット、デメリット的なものをそれぞれ挙げましたが、最後に答えをお伝えすると「食べる量」がとても重要になります。
アーモンドでも1粒おおよそ6Kcal~7Kcalほどあるので、10粒、20粒食べれば60Kcal〜120Kcal摂取することになります。

ナッツは健康に良いから、0カロリー！！！な訳ありませんし、食後のおやつとして食べても良いかもしれませんが、食事の一環として食べる方が思わぬ体重増加を防げると思います?